Session Initiation Protocol (SIP) is an application level protocol for creating, modifying and terminating multimedia sessions. Today, it is used for establishing and terminating voice, video, and/or messaging sessions over IP. Other feasible application examples include streaming multimedia distribution, sharing presence information, file transfer and online gaming.
An IMS network is an architectural framework for providing Internet Protocol (IP) multimedia services (e.g., Voice-over-IP telephony) to subscribers. Frequently, an IMS network utilizes SIP for session management and Session Description Protocol (SDP) for media negotiation. The IMS network generally includes three different layers: the application layer, the session layer, and the transport layer. The application layer includes application servers that provide various types of call support services to the subscribers. The session layer (also known as the IMS core network) manages user authentication, user equipment (UE) registration, and routing of signaling and other call-related packets between the application layer and the transport layer. The transport layer includes gateways that interface with various external networks (e.g., PSTN, Internet) and performs call control protocol conversion and transformation.
Various types of Call Session Control Function (CSCF) nodes (e.g., Proxy CSCF, Interrogating CSCF, Serving CSCF) are included as part of the session layer. The Serving CSCF (S-CSCF) nodes are generally configured as the central nodes in the session layer. The S-CSCF nodes perform several aspects of session control including, for example, handling UE registrations, determining to which application server(s) to forward messages, and enforcing policies of the IMS network operator. Any given deployment of an IMS network can include multiple S-CSCF nodes. The particular S-CSCF node that registers the UE of a subscriber is assigned dynamically at the time of UE registration. In addition, all subsequent messages from the UE are routed to the same S-CSCF node using standard IMS procedures.
Once the S-CSCF node is assigned, the Home Subscriber Server (HSS) stores the SIP Uniform Resource Locator (URL) for the assigned S-CSCF node against the SIP Address of Record (AOR) for the user. The Interrogating CSCF (I-CSCF) node queries the HSS to route subsequent registrations and terminating session setup requests to the assigned S-CSCF node.
The HSS is the central subscriber data repository for the network. The HSS stores the subscriber data which may include public user identities (e.g., SIP AOR) that the user may use, credentials to authenticate the user, and service settings for the user. The subscriber data stored at the HSS also contains the IMS service profile that is downloaded by the S-CSCF at the time of registration. This service profile contains a set of initial Filter Criteria (iFC) which instruct the S-CSCF as to which Application Servers should be chained in at the time of a session being established for the user. Each iFC contains a unique priority, a set of conditions which need to be evaluated against a received SIP message and, if the conditions match, an application server URI to which the request shall be forwarded.
The IMS standard also describes an extension to the service profile called shared iFC. If both the HSS and the S-CSCF support shared iFC, subsets of iFC may be shared by several service profiles. In this case, the HSS downloads the shared iFC sets implicitly by sending only the unique identifiers of the shared iFC sets to the S-CSCF. The S-CSCF is then expected to map each of the downloaded identifiers to its constituent iFC using a mechanism that is not specified in the IMS standard. For example, the identifier to iFC set mapping could be in a local database at the S-CSCF or in a shared database accessible to all S-CSCF nodes.
FIG. 1 is a diagram illustrating a typical call flow for registering a UE with an IMS network using inline initial filter criteria downloaded from the HSS. The IMS network 120 includes a P-CSCF node 104, an I-CSCF node 106, a S-CSCF node 108, an Application Server (AS) 110 and a HSS 112. The UE 102 connects to the IMS network 120 and attempts to register with the IMS network to access services provided by application servers (e.g., AS 110) in the IMS network. The first phase of registration is an authentication phase 130. During the authentication phase 130, the UE 102 sends a REGISTER message (step 130a) to the P-CSCF node 104, which transmits the REGISTER message (step 130b) to the I-CSCF node 106.
The I-CSCF node 106 then transmits a User-Authorization-Request (UAR) command (step 130c) to the HSS 112 in order to discover whether there is already a S-CSCF node bound to the requesting UE 102. The HSS 112 returns a User-Authorization-Answer (UAA) command (step 130d) to the I-CSCF node 106. The UAA may contain a S-CSCF name if the UE 102 is already bound to a particular S-CSCF node, or the UAA may contain S-CSCF capabilities that the I-CSCF node 106 can use to select a S-CSCF node (e.g., S-CSCF 108) to service the UE 102 in the event that the UE is not yet bound to a particular S-CSCF node (e.g., UE 102 was recently powered on).
Upon receipt of the UAA, the I-CSCF 106 selects and assigns a S-CSCF node 108 to the UE 102 using the S-CSCF capabilities received from the HSS 112 in the UAA. The I-CSCF 106 then forwards the REGISTER message (step 130e) to the assigned S-CSCF 108. The S-CSCF 108 transmits a Multimedia-Auth-Request (MAR) command (step 130f) to the HSS 112, indicating the URI associated with the assigned S-CSCF node 108. The HSS 112 stores the received S-CSCF URI and responds with a Multimedia-Auth-Answer (MAA) command (step 130g) that contains, among other information, authentication data associated with the UE 102. The S-CSCF node 108 then returns a “401 (Unauthorized)” message (steps 130h, 130i and 130j) to the UE 102 via the I-CSCF 106 and the P-CSCF 104. The “401 (Unauthorized”) message includes an authentication challenge that the UE 102 is directed to answer.
The second phase of registration (phase 140) begins with the UE 102 transmitting a new REGISTER message (step 140a) to the P-CSCF node 104 in response to the authentication challenge. The P-CSCF node 104 transmits the new REGISTER message (step 140b) to the I-CSCF 106, which queries the HSS 112 for the URI of the assigned S-CSCF node 108 via the use of a UAR command (step 140c). The HSS 112 responds to the I-CSCF 106 with a UAA command (step 140d) containing, among other information, the URI for the assigned S-CSCF 108.
The I-CSCF 106 then routes the new REGISTER message (step 140e) to the S-CSCF 108 by using the URI retrieved from the HSS 112. The S-CSCF node 108 validates the credentials contained in the new REGISTER message against the credentials that the S-CSCF had previously retrieved from the HSS 112 (in steps 130f and 130g). If the credentials are successfully validated, the S-CSCF 108 sends a Server-Assignment-Request (SAR) command (step 140f) to the HSS 112 for the purpose of informing the HSS that the UE 102 is now registered and to download the user profile associated with the UE 102. The HSS 112 responds with a Server-Assignment-Answer (SAA) command (step 140g) containing iFC of the retrieved user profile as inline data. As shown in FIG. 1, the SAA command contains “<iFC-1: priority 1, conditions, AS-1; iFC-2: priority 2, conditions, AS-2>”.
Upon receiving the SAA command containing the iFC, the S-CSCF node 108 transmits a “200 OK” message (steps 140h, 140i and 140j) to the UE 102 via the I-CSCF 106 and P-CSCF 104. The “200 OK” message indicates the success of the REGISTER request to the UE 102. At this point, the registration procedure is complete.
FIG. 2 is a diagram illustrating a typical call flow for registering a UE with an IMS using shared initial filter criteria downloaded from the HSS. The IMS network 220 includes a P-CSCF node 204, an I-CSCF node 206, a S-CSCF node 208, an AS 210 and a HSS 212. The UE 202 connects to the IMS network 220 and attempts to register with the IMS network to access services provided by application servers (e.g., AS 210) in the IMS network. The first phase of registration is an authentication phase 230. During the authentication phase 230, the UE 202 sends a REGISTER message (step 230a) to the P-CSCF node 204, which transmits the REGISTER message (step 230b) to the I-CSCF node 206.
The I-CSCF node 206 then transmits a UAR command (step 230c) to the HSS 212 in order to discover whether there is already a S-CSCF node bound to the requesting UE 202. The HSS 212 returns a UAA command (step 230d) to the I-CSCF node 206. The UAA may contain a S-CSCF name if the UE 202 is already bound to a particular S-CSCF node, or the UAA may contain S-CSCF capabilities that the I-CSCF node 206 can use to select a S-CSCF node (e.g., S-CSCF 208) to service the UE 202 in the event that the UE is not yet bound to a particular S-CSCF node (e.g., UE 202 was recently powered on).
Upon receipt of the UAA, the I-CSCF 206 selects and assigns a S-CSCF node 208 to the UE 202 using the S-CSCF capabilities received from the HSS 212 in the UAA. The I-CSCF 206 then forwards the REGISTER message (step 230e) to the assigned S-CSCF 208. The S-CSCF 208 transmits a MAR command (step 230f) to the HSS 212, indicating the URI associated with the assigned S-CSCF node 208. The HSS 212 stores the received S-CSCF URI and responds with a MAA command (step 230g) that contains, among other information, authentication data associated with the UE 202. The S-CSCF node 208 then returns a “401 (Unauthorized)” message (steps 230h, 230i and 230j) to the UE 202 via the I-CSCF 206 and the P-CSCF 204. The “401 (Unauthorized”) message includes an authentication challenge that the UE 202 is directed to answer.
The second phase of registration (phase 240) begins with the UE 202 transmitting a new REGISTER message (step 240a) to the P-CSCF node 204 in response to the authentication challenge. The P-CSCF node 204 transmits the new REGISTER message (step 240b) to the I-CSCF 206, which queries the HSS 212 for the URI of the assigned S-CSCF node 208 via the use of a UAR command (step 240c). The HSS 212 responds to the I-CSCF 206 with a UAA command (step 240d) containing, among other information, the URI for the assigned S-CSCF 208.
The I-CSCF 206 then routes the new REGISTER message (step 240e) to the S-CSCF 208 by using the URI retrieved from the HSS 212. The S-CSCF node 208 validates the credentials contained in the new REGISTER message against the credentials that the S-CSCF had previously retrieved from the HSS 212 (in steps 230f and 230g). If the credentials are successfully validated, the S-CSCF 208 sends a SAR command (step 240f) to the HSS 212 for the purpose of informing the HSS that the UE 202 is now registered and to download the user profile associated with the UE 202. The HSS 212 responds with a SAA command (step 240g) containing a shared iFC identifier of the retrieved user profile as inline data, instead of the complete iFC as described above with respect to FIG. 1. As shown in FIG. 2, the SAA command contains “<SiFC id: x>” where “x” is the shared iFC identifier.
Upon receiving the SAA command containing the shared iFC identifier, the S-CSCF node 208 maps the identifier to a list of iFC stored at the S-CSCF, and retrieves the iFC associated with the shared iFC identifier. The S-CSCF 208 uses the retrieved iFC for subsequent call processing. The S-CSCF 208 then transmits a “200 OK” message (steps 240h, 240i and 240j) to the UE 202 via the I-CSCF 206 and P-CSCF 204. The “200 OK” message indicates the success of the REGISTER request to the UE 202. At this point, the registration procedure is complete.
Generally, the usage of shared iFC between a HSS and a S-CSCF is desirable for at least the following reasons:                Easier provisioning: With shared iFC, a single copy of the shared data set is provisioned at the HSS instead of multiple copies of the iFC (i.e., one for every subscriber).        Faster processing and less resource consumption at the S-CSCF: Shared iFC allows a lesser amount of data to be exchanged between the S-CSCF and the HSS in registration flows because only the iFC identifier is passed as opposed to the iFC being sent as inline data. A result is faster profile parsing as well as efficient data storage at the S-CSCF (i.e., a single copy of the shared data can be referenced from multiple service profiles as opposed to multiple in-memory copies, one for each subscriber's profile).        Easier to update: In case of inline iFC being sent to the S-CSCF, if an iFC that is shared by all subscribers is altered at run-time, it results in significant traffic (e.g., one Diameter PPR per registered subscriber) between the HSS and the S-CSCF nodes. In case of shared iFC, any update of the shared data set results in one update notification which internally updates the profiles for all subscribers.        
When using shared iFC between the S-CSCF and the HSS, however, the IMS standards do not define the mechanisms to ensure provisioning of the same shared iFC set and its identifier at both the HSS and the S-CSCF. For example, if these network elements are provided by different vendors, there is presently a lack of a well-defined provisioning interface in the IMS standards that both the S-CSCF and the HSS must adhere to for shared iFC installation.
Also, the IMS standards do not presently define the mechanism to update the shared iFC set (or the identifiers) at both the HSS and the S-CSCF. This problem is compounded by the fact that if there are multiple HSS servers (e.g., for geo-redundancy) and multiple S-CSCF nodes (e.g., for network scalability), the shared iFC do not need to be synchronized between only two databases but must be synchronized across multiple databases. Therefore, what is needed is a mechanism to provision shared iFC and to update them at a later point of time such that all of the HSS servers and all of the S-CSCF nodes in an IMS network are in sync at any point of time with regard to the shared iFC.